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Abstract 


This document describes a Dynamic Host Configuration Protocol for 
IPv6 (DHCPv6) option for specifying an upper bound for how long a 
client should wait before refreshing information retrieved from 
DHCPv6. It is used with stateless DHCPv6 as there are no addresses 
or other entities with lifetimes that can tell the client when to 
contact the DHCPv6 server to refresh its configuration. 
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1. Introduction 


DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts. 
However, many hosts will use stateless autoconfiguration as specified 
in [RFC2462] for address assignment, and use DHCPv6 only for other 
configuration data; see [RFC3736]. This other configuration data 
will typically have no associated lifetime, hence there may be no 
information telling a host when to refresh its DHCPv6é configuration 
data. Therefore, an option that can be used from server to client to 
inform the client when it should refresh the other configuration data 
is needed. 


This option is useful in many situations: 


- Unstable environments where unexpected changes are likely to 
occur. 


- For planned changes, including renumbering. An administrator 
can gradually decrease the time as the event nears. 


—- Limit the amount of time before new services or servers are 
available to the client, such as the addition of a new NTP 
server or a change of address of a DNS server. See [RFC4076]. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


3. Information Refresh Time Option Definition 


The information refresh time option specifies an upper bound for how 
long a client should wait before refreshing information retrieved 
from DHCPv6. It is only used in Reply messages in response to 
Information-Request messages. In other messages there will usually 
be other options that indicate when the client should contact the 
server, e.g., addresses with lifetimes. 


Note that it is only an upper bound. If the client has any reason to 
make a DHCPv6 request before the refresh time expires, it should 


attempt to refresh all the data. 


A client may contact the server before the refresh time expires. 
Reasons it may do this include the need for additional configuration 
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parameters (such as by an application), a new IPv6 prefix announced 
by a router, or that it has an indication that it may have moved to a 
new link. 


The refresh time option specifies a common refresh time for all the 
data. It doesn’t make sense to have different refresh time values 
for different data, since when the client has reason to refresh some 
of its data, it should also refresh the remaining data. Because of 
this, the option must only appear in the options area of the Reply 
message. 


The expiry of the refresh time in itself does not in any way mean 
that the client should remove the data. The client should keep its 
current data while attempting to refresh it. However, the client is 
free to fall back to mechanisms other than DHCPv6 if it cannot 
refresh the data within a reasonable amount of time. 


When a client receives a Reply to an Information-Request that 
contains configuration information, it should install that new 
configuration information after removing any previously received 
configuration information. It should also remove information that is 
missing from the new information set, e.g., an option might be left 
out or contain only a subset of what it did previously. 


3.1. Constants 


We define two constants for use by the protocol. How they are used 
is specified in the sections below. 


IRT_DEFAULT 86400 
In some cases the client uses a default refresh time 
IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 
(24 hours). The client implementation SHOULD allow for this 
value to be configurable. 


IRT_MINIMUM 600 
This defines a minimum value for the refresh time. 


3.2. Client Behaviour 
A client MUST request this option in the Option Request Option (ORO) 
when sending Information-Request messages to the DHCPv6 server. A 
client MUST NOT request this option in the ORO in any other messages. 
If the Reply to an Information-Request message does not contain this 


option, the client MUST behave as if the option with value 
IRT_DEFAULT was provided. 
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A client MUST use the refresh time IRT_MINIMUM if it receives the 
option with a value less than IRT_MINIMUM. 


As per section 5.6 of [RFC3315], the value Oxffffffff is taken to 
mean "infinity" and implies that the client should not refresh its 
configuration data without some other trigger (such as detecting 
movement to a new link). 


If a client contacts the server to obtain new data or refresh some 
existing data before the refresh time expires, then it SHOULD also 
refresh all data covered by this option. 


When the client detects that the refresh time has expired, it SHOULD 
try to update its configuration data by sending an Information- 
Request as specified in section 18.1.5 of [RFC3315], except that the 
client MUST delay sending the first Information-Request by a random 
amount of time between 0 and INF_MAX DELAY. 


A client MAY have a maximum value for the refresh time, where that 
value is used whenever the client receives this option with a value 
higher than the maximum. This also means that the maximum value is 
used when the received value is "infinity". A maximum value might 
make the client less vulnerable to attacks based on forged DHCP 
messages. Without a maximum value, a client may be made to use wrong 
information for a possibly infinite period of time. There may 
however be reasons for having a very long refresh time, so it may be 
useful for this maximum value to be configurable. 


3.3. Server Behaviour 
A server sending a Reply to an Information-Request message SHOULD 
include this option if it is requested in the ORO of the Information- 


Request. 


The option value MUST NOT be smaller than IRT_MINIMUM. The server 
SHOULD give a warning if it is configured with a smaller value. 


The option MUST only appear in the options area of Reply messages. 
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3z 


4. 


4. Option Format 
The format of the information refresh time option is: 


0 1 2 3 
012345678901234567890123456789041 
+-4-4+-4-4-4-4-4-4-4-4+-4-4-4+-4+-4-4+-4-4-4-4+-4+-4+-4+-4+-4+-4+-4-4-4-4-4-4 

| option-code | option-len 
+-4-4-4-4-4-4-4-4+-4-4+-4-4-4+-4+-4+-4+-4-4-4+-4+-4+-4-4-4-4-4-4-4-4-4-4-4 
| information-refresh-time 
+-4+-4-4-4-4-4-4-4+-4-4-4-4-4-4+-4-4-4-4-4-4-4-4+-4+-4-4-4-4-4-4-4-4-4 


option-code 
OPTION_INFORMATION_REFRESH_TIME (32) 


option-len 
4 


information-refresh-time 
Time duration relative to the current time, expressed in units 
of seconds 


IANA Considerations 


The IANA has assigned an option code for the information refresh time 
option from the DHCPv6 option-code space [RFC3315]. 
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Security Considerations 


Section 23 of [RFC3315] outlines the DHCPv6 security considerations. 
This option does not change these in any significant way. An 
attacker could send faked Reply messages with a low information 
refresh time value, which would trigger use of IRT_MINIMUM to 
minimize this threat. Another attack might be to send a very large 
value, to make the client use forged information for a long period of 
time. A possible maximum limit at the client is suggested, which 
would reduce this problem. 
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